|
|
|
|
|
|
|
Solution 8
Playing Leapfrog |
|
|
|
|
|
|
|
|
You probably figured out the first problem quickly. There are two reasons why a function might not be found in a DLL: You have either the wrong DLL or the wrong function name. The operating system version number is as closely tied to the operating system as a function can get, so kernel32 is the logical DLL to hold the function. And in fact, that's where the function is. So the name must be wrong. |
|
|
|
|
|
|
|
|
There are only two reasons why a system function would have a different name in the DLL than what you see in the documentation. Occasionally, the documentation describes a C macroa name that translates into a series of C function calls. Fortunately, this is very rare, and these situations are typically described in the documentation. |
|
|
|
|
|
|
|
|
Most often, the problem is that the function takes a string parameter, thus it appears in the DLL with two entry points: the ANSI entry point with an A suffix and a Unicode entry point with a W suffix. |
|
|
|
|
|
|
|
|
But the GetVersionEx function doesn't take a string parameter, so how can this be the problem? |
|
|
|
|
|
|
|
|
Wait a minute! Look again at the OSVERSIONINFO structure: |
|
|
|
|
|
|
|
|
Private Type OSVERSIONINFO
dwOSVersionInfoSize As Long
dwMajorVersion As Long
dwMinorVersion As Long
dwBuildNumber As Long
dwPlatformId As Long
szCSDVersion As String * 128 ' Remember VB arrays are zero based!
End Type |
|
|
|
|
|
|
|
|
Sure enough, the structure has a string. That means that the function does, indeed, need two entry points: one that can handle an ANSI string within a structure and another that can handle the Unicode string. The corrected declaration is therefore as follows: |
|
|
|
|
|
|
|
|
Private Declare Function GetVersionEx Lib "kernel32" Alias _
"GetVersionExA" (os As OSVERSIONINFO) As Long |
|
|
|
|
|
|
|
|
The function still fails, however, returning a 0 (invalid) result. |
|
|
|
|
|